The following text was written by Scott Dudley, author of MAXIMUS, one of the most common BBS systems in use on the planet. Scott has also written a mail processor called SQUISH which is also a world leader in processing Fidonet mail. The following was taken from the documentation file for Squish with the kind permision of Mr. Dudley. NETWORK PRIMER by, Scott Dudley 1:249/106 This section is intended as a primer for SysOps who are new to FidoNet or a FidoNet Technology Network (FTN). This section covers many of the terms and concepts which are required for everyday FidoNet operations. The Basics The term "FidoNet" refers to an amateur electronic mail network, run collectively by a group of system operators. In the beginning, FidoNet started out as a simple system for exchanging private messages between different bulletin boards. Since then, FidoNet has grown into a full-fledged electronic mail and conferencing network which has members in most countries of the world. FidoNet itself is organized into a numerical hierarchy of "zones", "regions", "nets", "nodes" and "points". Each member of FidoNet, individually known as a "node", can be uniquely identified by that system's zone, net, node and point numbers. To define each term: Zones are wide geographical areas, usually covering one or more continents. At the time of writing, FidoNet currently has six zones: zone 1 (North America), zone 2 (Europe), zone 3 (Oceania), zone 4 (South America), zone 5 (Africa) and zone 6 (Asia). Nets cover a much smaller area than zones; a net usually encompasses a large city and the surrounding area. There are usually many nets within each zone, each of which represents a small geographical area within that zone. Nodes are individual systems. Most nodes consist of bulletin board systems, although a few nodes are devoted exclusively to handling mail. If you wish to become a member of FidoNet and you are running a BBS, this is probably where you will start. Points are users on an individual system. Normally, points do not run full-time systems, since they simply send and receive mail through their "bossnodes" (the nodes where the points pick up their mail). As the size of the network grows, points are becoming increasingly popular. If you don't wish to run a full- time system, this is probably where you'll start. These four terms can be combined to give a "network address" which identifies any one node in the network. The format of a FidoNet address is as follows: zone:net/node[.point] For example, given a user in zone 1, in net 249, with a node number of 106, and a point number of 2, that user's full address would be '1:249/106.2'. The point number is optional, so both 1:249/106 and 1:249/106.0 refer to the bossnode of 1:249/106.2. This mode of addressing is sometimes referred to as "4D" or four- dimensional, since it includes the four basic elements of a network address. The Outside World Like other electronic mail systems, it's possible to enter a private message on a FidoNet system and have that message be delivered to its final destination in a short period of time. FidoNet systems "talk" with each other over telephone lines, using one or more sophisticated handshaking protocols. To get a message (known in this context as "NetMail") from point "A" to point "B", the following sequence of events has to occur: * The message is created. Most Fido-compatible software packages can be used to generate a private message to a user on another node. The destination address is entered, using the standard 4D addressing scheme. * The on-disk message is then converted to packet (or *.PKT) form. If you are running BinkleyTerm, this will be performed by Squish after a user logs off. If you are running FrontDoor or a similar mailer type, this will be performed by the mailer itself on startup, or while your mailer is connected to other systems. There are four reasons for converting a message into a packet: 1) The packet structure is much more flexible than the local message structure. All of the fields (such as the To:, From: and Subject: fields) in a packet are variable length, whereas the fields in stored messages are fixed-length. 2) Packets are the "compatibility layer". Since all systems convert messages to the *.PKT format before sending them to another system, there are few compatibility problems. This means that systems can store their local message bases in different formats, but still be able to exchange messages easily. In addition, more than one message can be stored in a single packet. Sometimes hundreds (or even thousands) of messages can be stored in a single packet. 3) Messages in a packet can have a different address from the packet itself. The packet itself has a destination (the system where you'll be sending that packet directly to), but each message has an individual destination address. This is useful, for example, when a long-distance call is required to connect with certain parts of the network. The message's final destination always stays the same, but by sending the packet to someone who is local to you (and then having that someone send it to another local system, and so on), costs can be controlled quite effectively. Since the interim destination of packet doesn't need to be the same as the final destination of the message, routing of messages via the lowest-cost route can be performed. 4) Packets can be given a "flavour". A "flavour" (or a behaviour characteristic) helps your system decide what to do with an individual message. For example, the "hold" flavour instructs your system to hold the message and wait for the destination system to call and pick it up. Other flavours include "crash" (send a message directly to the destination), "direct" (same as crash), and "normal" (wait for later routing commands). Packets always have an extension of *.PKT. (Qualifier: if you are running a BinkleyTerm system, they may have an extension of *.HUT, *.OUT, *.CUT, or *.DUT on your local system, but Binkley always changes them to *.PKT files before they are sent to another system.) * After the packet is created, it can be optionally archived using a file compression utility. Compression is useful when transferring large volumes of mail or sending to long- distance sites, since compressing mail saves both time and money. * The system which created the message then tries to call the destination system. Obviously, if both systems are fairly busy, this may take a while. Messages are sent back and forth between systems through the use of mailers, also known as "front ends". Mailers call out to deliver waiting mail, handle incoming messages and files, and in general, supervise the entire file transfer. * After the two mailers connect (using one of several FidoNet protocols), waiting mail and files are transferred between the two systems. * After the transfer completes, the receiving system then tries to import the message. If the packet was compressed by the sender, it will be decompressed. The *.PKT files will then be imported (otherwise known as "tossed") into the local message base, ready for the recipient to read. Although transferring NetMail can involve much more than just what is given above, this should give you a grasp on NetMail fundamentals. Is There an Echo In Here? In the beginning, FidoNet consisted solely of nodes exchanging NetMail. The only way to get a message from "here" to "there" was to send a private NetMail message. However, a technology called "EchoMail" was developed in late 1985; EchoMail is analogous to a public message area or conference, but EchoMail areas (sometimes known as "echoes") are shared among several other systems. EchoMail is organized into different groups of echoes, each with a different topic. For example, the topics of FidoNet echoes range from Maximus Support to deep-sea fishing and many more special-interest groups. To facilitate topic-oriented EchoMail, each echo must given a tag (or area name). This tag is used to uniquely identify that EchoMail area when transferring messages with other systems. (It doesn't matter what you call the echo on YOUR system, as long as you are using the same tag as everyone else.) Area tags are one word only, although they can include periods and underscores. To start receiving an echo area, you need to know the tag of that area. For example, the area tag for the echo dealing with hardware and other technical issues is "TECH". EchoMail messages are normally public, and they are entered in a message area just like a normal message. EchoMail messages also look like normal, locally-entered messages, but with some special control information at the bottom of each message. After an EchoMail message is saved, an EchoMail utility (such as Squish) is invoked to "scan" that message out to the rest of the network. Unlike NetMail, EchoMail areas have an electronic topology. Some echoes are very large, and as such, the cost to directly send a message to each system which carried that echo would be prohibitive. Instead, each system carrying that echo only transfers EchoMail messages to neighbouring systems. (The neighbour you receive an echo from is also known as your "feed".) EchoMail messages get sent from the originating system to its neighbours, and from those systems to their neighbours, and so on. Despite this "hoppity-hop" method of transferring messages, EchoMail is fairly quick; it can often take less than three days for a message to travel from the USA to Australia and back. Just like NetMail, echoes are sent to other systems in packets. EchoMail messages are almost always compressed, since most of the popular echoes have a daily throughput anywhere from 20 to 200 messages per day. Copyright 1991 by Scott J. Dudley. All rights reserved. Used with permission. * * *